With jitter- and/or delay-sensitive applications such as Video on Demand (VoD) and Voice over Internet Protocol (VoIP) over an Internet Protocol (IP) core, two generic methods are currently used to assure the quality of connections. One method uses Resource reSerVation Protocol (RSVP) to reserve bandwidth, and the other relies on pure IP routing. The first method takes advantage of RSVP to guarantee reserved bandwidth at all times, which might not result in a resource-optimized core. The second method requires centralized bandwidth management to guarantee reserved bandwidth at connection creation time or in network failure scenarios, since an IP network is not aware of how its links are actually used.
In order to manage connections and their needed bandwidths, the routing path and the required bandwidth for each connection must be known.
When routing path endpoints lie in different routing areas of a communication system, calculation of routing paths can become time- and resource-intensive. In a centralized routing path calculation model, for example, inter-area routing path calculation would require the collection and maintenance of up-to-date routing information for all routing areas at a centralized location, and processing of that information at the centralized location each time a routing path is to be calculated. The amount of routing information to be collected and maintained can itself be problematic in terms of storage requirements. Processing of this routing information at a centralized location can also introduce time delays where multiple routing paths are to be calculated. A centralized processing scheme might be limited in terms of the number of routing paths that it can calculate simultaneously, for instance.
There may also be potential issues with change handling in a centralized model. For example, it will take time for changes in a communication system to be reflected in a centralized database. In addition, any such change may necessitate the recalculation of all routing paths by a centralized routing path calculator. A centralized routing path calculator might not be able to determine which particular routing paths could be affected by a change, and accordingly may recalculate all routing paths. This would not be an effective use of resources, especially where a change does not actually have any effect on a majority of existing paths.
Considering routing path calculations themselves, some routing protocols enable paths between communication system nodes to be pre-configured. A path between two nodes might be specially configured to handle a certain Class of Service (CoS), for example. According to conventional routing path calculation schemes, such pre-configured paths are only taken into account if they originate at the source node of a routing path currently being calculated. Such paths may originate at intermediate nodes along a routing path, but are not used when calculating a routing path that traverses such intermediate nodes.
Thus, there remains a need for improved routing path calculation techniques.